Skip to content

bubblewrap: Add --not-a-security-boundary flag to enable fail-open behavior#751

Open
ao2 wants to merge 1 commit into
containers:mainfrom
ao2:ao2/not-a-security-boundary
Open

bubblewrap: Add --not-a-security-boundary flag to enable fail-open behavior#751
ao2 wants to merge 1 commit into
containers:mainfrom
ao2:ao2/not-a-security-boundary

Conversation

@ao2
Copy link
Copy Markdown
Contributor

@ao2 ao2 commented May 7, 2026

Some callers of bwrap (e.g. xdg-dbus-proxy, Steam Runtime) use it purely to adjust filesystem layout, without any expectation of a security boundary between the sandbox and the host.

For these callers, hard failures during sandbox setup (such as an automount timeout on a bind source) are unnecessarily fatal.

So add a new --not-a-security-boundary option that can be used to relax the bubblewrap behavior in these specific cases, and allow it to "fail-open".

@ao2 ao2 changed the title bubblewrap: Add --not-a-security-boundary flag to enable fail-open … bubblewrap: Add --not-a-security-boundary flag to enable fail-open behavior May 7, 2026
@ao2
Copy link
Copy Markdown
Contributor Author

ao2 commented May 7, 2026

cc @smcv even though it's still a draft

Comment thread bubblewrap.c Outdated
…behavior

Some callers of bwrap (e.g. xdg-dbus-proxy, Steam Runtime) use it purely
to adjust filesystem layout, without any expectation of a security
boundary between the sandbox and the host.

For these callers, hard failures during sandbox setup (such as an
automount timeout on a bind source) are unnecessarily fatal.

So add a new `--not-a-security-boundary` option that can be used to
relax the bubblewrap behavior in these specific cases, and allow it to
"fail-open".

In the first implementation enable the "fail open" behavior only to the
case where bwrap fails to remount a submount with different flags during
a `--bind` or `--bind-fd` operations, and still "fail close" for
operations like `--dev-bind` and `--ro-bind` which are supposedly more
critical.

Signed-off-by: Antonio Ospite <antonio.ospite@collabora.com>
@ao2 ao2 force-pushed the ao2/not-a-security-boundary branch from e64137e to 418a4f1 Compare May 11, 2026 16:29
@ao2 ao2 marked this pull request as ready for review May 13, 2026 11:14
@smcv smcv self-requested a review May 18, 2026 10:46
Copy link
Copy Markdown
Collaborator

@smcv smcv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like some smoke-test coverage for this in the test suite. Setting up a failing automounter (so that there will genuinely be an error to ignore) is probably too difficult to do in bubblewrap's test suite, but we can at least exercise the happy path where the new option makes no practical difference.

Comment thread bubblewrap.c
(op->type == SETUP_DEV_BIND_MOUNT ? BIND_DEVICES : 0) |
((op->type == SETUP_BIND_MOUNT &&
opt_not_a_security_boundary) ? BIND_FAIL_OPEN : 0),
source, dest);
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does only --bind fail open? If bubblewrap is not a security boundary, shouldn't --dev-bind and --ro-bind be equally willing to fail open?

Separately, I think we're getting enough flags that the repeated ?: operators make it harder to read, and it would be better more like:

bind_option_t bind_flags = 0;

if (opt_not_a_security_boundary)
  bind_flags |= BIND_FAIL_OPEN;

if (op->type == SETUP_RO_BIND_MOUNT)
  bind_flags |= BIND_READONLY;

if (op->type == SETUP_DEV_BIND_MOUNT)
  bind_flags |= BIND_DEVICES;

/* etc. */

setup_op_bind_mount (bind_flags, source, dest);

@smcv
Copy link
Copy Markdown
Collaborator

smcv commented May 18, 2026

The commit message should have a Resolves: https://github.com/containers/bubblewrap/issues/653, and optionally also:

  • Helps: https://github.com/flatpak/flatpak/issues/5112
  • Helps: https://github.com/ValveSoftware/steam-for-linux/issues/10571
  • Helps: https://github.com/ValveSoftware/steam-runtime/issues/766

Optionally also a mention of steamrt/tasks#535.

@smcv
Copy link
Copy Markdown
Collaborator

smcv commented May 18, 2026

For manual testing, I see you've described how to reproduce the problem in ValveSoftware/steam-for-linux#10571 (comment) (it might be useful to summarize that in the commit message). It would be useful if you could create other mount points - perhaps /mnt/bad for the broken automount, and /mnt/good for a loopback mount that is working correctly - and then inspect /proc/self/mountinfo inside the container to see what happens after the error is ignored.

What I expect will happen is that /mnt/good will be remounted nodev, but the broken automount at /mnt/bad might lack the nodev option.

Similarly, if you request mounting them read-only, something like --ro-bind /mnt /mnt, I expect that /mnt/good will be remounted ro, but /mnt/bad will still be rw, which is why we need to fail closed for the default "yes, security boundary" use-case.

But it would be good to confirm this.

Comment thread bwrap.xml
host system. When this option is given, certain non-fatal sandbox
setup failures (such as a bind mount failing because an automounter
did not respond in time) will produce a warning and will be skipped,
rather than causing <command>bwrap</command> to exit with an error.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps worthwhile to say something like

Suggested change
rather than causing <command>bwrap</command> to exit with an error.
rather than causing <command>bwrap</command> to exit with an error.
The effect of this option might be extended to make other sandbox
setup operations non-fatal in future releases of bubblewrap.

to give us space to make more operations fail open if we find that it's desirable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants